Password Encryption Key

ABSTRACT

A password-encrypted key (PEK) is generated from a user-supplied password or other identifying data and then used to encrypt the user&#39;s password. The encrypted password is stored in a user record on a server. At login a would-be user&#39;s password is again used to make a key, which is then used to decrypt and compare the stored encrypted password with the would-be user&#39;s password to complete the login. The successful PEK is stored in a temporary session record and can be used to decrypt other sensitive user information previously encrypted and stored in the user record as well as to encrypt new information for storage in the user record. A public/private key system can also be used to maintain limited access for the host to certain information in the user record.

CLAIM OF PRIORITY

This application claims priority under 35 USC 119(e) to U.S. PatentApplication Serial No. 60/421,284 filed on Oct. 25, 2002, the entirecontents of which are hereby incorporated by reference.

TECHNICAL FIELD

This invention relates to eSecurity and more particularly to userauthentication.

BACKGROUND

A frequently neglected aspect of the modem enterprise data storage issensitive user information security. The most widespread approach usedtoday is encryption of such user information as Social Security number,credit card numbers, e-mails, etc. with a single key and storage of theresulting encrypted data in the database. The logic behind such solutionis that a malicious individual who gains access to the database will beunable to make use of the user's sensitive data because it is encrypted.

Unfortunately, this approach provides a false sense of security in mostcases. The problem is that the encryption key used to encrypt allrecords still needs to be stored somewhere in the system. For example,as soon as the system is required to send e-mail to the user or submituser's credit card number to the merchant account, the server(s)responsible for fulfilling that requirement must use the key to decryptuser information retrieved from the database. Chances are that if amalicious individual manages to get access to the database, which isusually the most protected part of the system, he will then be able togain access to the aforementioned server. As soon as this happens, suchmalicious individual will be able to obtain the key and decrypt everydatabase record encrypted with this key.

SUMMARY

A password-encrypted key (PEK) is generated from a user-suppliedpassword, for example, and then used to encrypt the user's password. Theencrypted password is stored in a user record on a server. At login, awould-be user's password is again used to make a key, which is then usedto decrypt and compare the stored encrypted password with the would-beuser's password to complete the login. The successful PEK is stored in atemporary session record and can be used to decrypt other sensitive userinformation previously encrypted and stored in the user record as wellas to encrypt new information for storage in the user record. Apublic/private key system can also be used to maintain limited accessfor the host to certain information in the user record.

According to one aspect of the invention, a secure transaction processincludes generating a key from a user-supplied unencrypted password orother identifying data, encrypting the user's password with the key,creating a user record and storing the encrypted password in the userrecord. In another aspect of the invention, upon user login, a key ismade from a would-be user's password using the same algorithm used togenerate the key from the originally supplied unencrypted password, thenthe encrypted password in the corresponding user record is retrieved anddecrypted using the key and the decrypted password and the would-beuser-supplied password are compared to see if they match.

In the preferred process, if the decrypted password and user-suppliedpassword match, a temporary session record is created and the key isstored in the session record. In the absence of a match, the user loginprocedure for secure or user-authenticated transactions at least wouldpreferably be aborted or terminated in some fashion.

The key may be used to encrypt other sensitive user data, which can bestored in the user record. During a session in which a session recordhas been created, the key stored in the session record can be used todecrypt the other encrypted information stored in the user record foruse in carrying out some desired action.

Alternatively, a public/private key pair or other asymmetriccryptography can be employed. A public/private key pair is generated andthe public key is stored on an application server and the mating privatekey only on another server, preferably a secure off-site server. Theoriginal user-supplied unencrypted password is then encrypted with thepublic key and stored on the application server. Subsequently, theprivate key can be fetched from the other server and used to decryptselected information on the one server, for example, for a mass mailing.A single public/private key can support the entire site.

The password encryption key (PEK) system of the present inventioneliminates one of the shortcomings of prior methods by using a uniqueencryption key for each user record. This key is based on at least onepiece of data—user password. Optionally, user name (or user ID) can beused in conjunction with user password. User's password (and name) isobtained at each successful user login and is maintained by the systemfor the duration of that user's session.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a flowchart showing the user registration process.

FIG. 2 is a data structure diagram of the user record.

FIG. 3 is a flowchart showing the user login process.

FIG. 4 is a data structure diagram of the session record.

FIG. 5 is a flowchart showing a process for safely storing sensitiveinformation.

FIG. 6 is a flowchart showing the process for safely retrieving andusing stored sensitive information, which has been encrypted.

FIG. 7 is a flowchart showing an alternative registration process usinga public key.

FIG. 8 is a flowchart showing the process for extracting e-mailaddresses using public/private key pairs stored in the process of FIG.7. Like reference symbols in the various drawings indicate likeelements.

DETAILED DESCRIPTION

PEK Integration into the System

The PEK system is illustrated as a sequence of processes as shown inFIGS. 1, 3, 5 and 6, running on an application server or other computersystem. Preferably all of the processes are carried on the Internet on aserver that hosts a given application accessed remotely by a user fromhis or her personal computer, for example.

1. User Registration Process (FIG. 1)

a. User registers by, at least, providing new username and an arbitrarypassword.

b. Generate a key from the password. (and optionally username/ID). A keycan be generated by calculating an MD5 checksum of the source data.

c. Encrypt user password with the key obtained at step 1 b. Note: othersensitive data provided during registration (i.e. e-mail address) shouldalso be encrypted with the same key.

d. Create new user record (FIG. 2) and store username, encryptedpassword and other optional data (sensitive data encrypted) in that userrecord.

2. User Login Process (FIG. 3)

a. User logs in providing username/password for authentication.

b. Generate a key from the password (and optionally username/ID). Thiskey should be identical to the key obtained at step 1 b.

c. Retrieve user record by username and decrypt user password using thekey obtained at step 2 b.

d. Compare the decrypted password to the one provided by user at step 2a.

e. Reject user login if passwords do not match. Abort login process.

f. If passwords match, create a temporary user session record (FIG. 4)that will exist for the duration of the user session. (A user session isa temporary data pool created after user login and destroyed as a resultof explicit user logout or session timeout. Session timeout occurs aftera certain pre-determined period of user inactivity.)

g. Store resulting key in the session.

h. Communicate session ID back to the user (client application). SessionID is a number or string uniquely identifying the session. Once user(client application) receives the session ID from the system, user willalways provide that ID with each subsequent request for the duration ofthe session. This enables the system to get access to user session dataat each request.

3. Sensitive Information Storage (FIG. 5)

a. User submits some sensitive data (i.e. Credit Card number).

b. Encrypt sensitive data with a key retrieved from user's session.

c. Store encrypted data in user's record if it is to be permanentlymaintained on the server. If it is only to be available for the sessionthen the encrypted data would be stored only temporarily in the sessionrecord.

4. Sensitive Information Retrieval (FIG. 6)

a. User requests some system action requiring use of the informationstored at step 3. (i.e. user decides to make a purchase with the creditcard that he/she previously submitted to the system).

b. Retrieve a key (i.e., the PEK) from the user's session record (FIG.4).

c. Decrypt the necessary data using the key obtained at step 4 b.

d. Perform the required action with decrypted data (i.e. send it to themerchant account)

e. Discard decrypted data.

Implications

The system, at user's request, can decrypt data stored in the databaseat step 3 (FIG. 5), at any time while that user's session is active. Assoon as user's session expires, it should be impossible to decrypt thisuser's sensitive information without knowing the user's password. Notethat user's password is also encrypted at step 1 c (FIG. 1).

Thus, a user's sensitive data will always be as secure as the user'spassword in this system. In the majority of cases, this should beacceptable since knowledge of password only gives access to sensitiveuser account information through the standard interface anyway.

Potential Vulnerabilities and Solutions

While PEK offers a secure way of protecting user data for users that arenot currently logged in, in theory, it could be possible for a maliciousindividual to gain access to sensitive data for users that are currentlylogged in (i.e. have active sessions going). Such individual would haveto obtain all of the encrypted user data and all of the active sessionsdata, extract a key from each session, and decrypt the active user'ssensitive data by applying extracted keys to corresponding user records.

Logged in users, however, in most cases, represent only a small subsetof all registered users and that alone greatly limits the scope ofpotential risks. In addition, the exposure can be further limited bymaking sure that the information linking session to a specific user,like username/ID, is not stored in session data. Instead, thisinformation can be provided by the client application with each user'srequest. That alone would make it exceedingly difficult for a maliciousindividual to match a key, retrieved from any given session, to aspecific user record.

Other Considerations

PEK makes it difficult to perform legitimate system functions thatinvolve access to sensitive user data without an explicit user request.Bulk mailing to all system users is a good example. Suppose that usere-mails or at least e-mail addresses are encrypted using PEK. It willthen be impossible for the system to decrypt user e-mails because eache-mail is encrypted with its owner's password and that password itselfis also encrypted.

One solution to this problem is to utilize asymmetric cryptography, likePGP, and keep a copy of the user's password, encrypted with a publickey, in the main database, as shown in FIG. 7. Only one pair ofpublic/private keys for the entire site needs to be generated inadvance; then the public key, used for encryption, should be stored onthe application server, while the private key, used for decryption,should be stored on an off-site secure server. This server, at the timeof bulk mailing, as shown in FIG. 8, will decrypt user's password usingthat private key, generate user's PEK as described in step 1 b, and,finally, decrypt required information using PEK. The main advantage ofthis approach is that it should be possible to keep the server, whichmaintains the private key, either off-site or in a special securityzone. This setup will ensure that while this server will be able toaccess the system data, the system would not be able to access theserver. To further enhance security, this server can also be completelyinaccessible (i.e. down) when bulk operations are not in progress.

Another approach is to use the public key to directly encrypt only thoseuser record fields that require bulk access. Distinct public/private keypairs can be used to encrypt different field types (i.e. e-mails andCredit Card numbers). This would allow, for a more refined accesspermissions control. For example, bulk mail server will only have aprivate key that decrypts e-mails, but not Credit Card numbers.

Finally, yet another approach could be to push unencrypted data to theoff-site server at the time of its submission by user. This is the leastsecure approach but it allows the most flexibility.

A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention. Forexample, instead of MD5 checksum, some other encryption algorithm orreproducible key-making methodology could be used. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A secure transaction process, comprisinggenerating a key from a user-supplied unencrypted password, encryptingthe user's password with the key, creating a user record, storing theencrypted password in the user record.
 2. The process of claim 1,further comprising upon user login, generating a key from a would-beuser's password using the same algorithm used to generate the key fromthe originally supplied unencrypted password, retrieving thecorresponding user record, decrypting the encrypted password in the userrecord using the key, comparing the decrypted password with the would-beuser-supplied password to see if they match.
 3. The process of claim 2,further comprising if the decrypted password and user-supplied passwordmatch, creating a temporary session record and storing the key in thesession record, otherwise aborting the user login.
 4. The process ofclaim 3, further comprising encrypting other sensitive user data usingthe key and storing the encrypted data in the user record, during asession wherein a session record has been created, using the key storedin the session record to decrypt other encrypted information stored inthe user record for use in carrying out some desired action.
 5. Theprocess of claim 1, further comprising generating a public/private keypair, storing the public key on an application server and the matingprivate key only another server, encrypting the original user-suppliedunencrypted password with the public key and storing the public-keyencrypted password on the application server, fetching the private keyfrom the other server and using it to decrypt selected information onthe one server.
 6. The process of claim 5, further wherein the otherserver is a secure off-site server.
 7. A secure transaction process,comprising generating an encryption key from user-suppliedidentification data, encrypting the user's identification data with thekey, creating a user record, storing the encrypted identification datain the user record.
 8. The process of claim 7, further comprising uponuser login, generating a key from a would-be user's identification datasupplied at login using the same algorithm used to generate the key fromthe originally supplied unencrypted identification data, retrieving thecorresponding user record, decrypting the encrypted identification datain the user record using the key, comparing the decrypted identificationdata with the would-be user-supplied identification data to see if theymatch.
 9. The process of claim 8, further comprising if the decryptedidentification data and user-supplied identification data match,creating a temporary session record and storing the key in the sessionrecord, otherwise aborting the user login.
 10. The process of claim 9,further comprising encrypting other sensitive user data using the keyand storing the encrypted data in the user record, during a sessionwherein a session record has been created, using the key stored in thesession record to decrypt other encrypted information stored in the userrecord for use in carrying out some desired action.